Como a convivência com banco de dados já completou mais de 50 anos algumas observações quanto a estruturação dos dados numa tabela ou banco de dados ganharam notoriedade porque estabeleceram regras que proporcionam ganhos consideráveis na sua utilização.

Como veremos adiante não existe nada grátis, ou seja, perfeito. Seja qual for a regra que você utilize ela apresenta vantagens quando utilizada corretamente, em determinadas circunstâncias. O objetivo deste documento é mostrar essas 'circunstâncias' e as melhores oportunidades da utilização delas.

O que é entidade ?

Chamaremos de 'Entidade' a representação de qualquer 'item' em nosso banco de dados. Esses itens podem ser qualquer coisa importante o suficiente para querermos armazenar em nosso banco de dados como clientes, vendas, pagamentos etc.

O que Normalização ?

A Normalização segue as regras que qualquer DBA desejaria. Nesse tipo de estruturação de dados cada tabela contém apenas os dados de uma entidade . Então se tenho uma tabela de clientes ela não conterá dados de vendas ou qualquer outra 'entidade' de nosso banco de dados. Portanto, uma tabela normalizada só contém dados de uma 'entidade' de nosso banco de dados.

Vantagens da Normalização ?

Exemplo: Se eu tenho uma tabela no meu banco de dados chamada clientes e eu preciso achar um dado referente ao cliente eu não precisarei procurar em nenhum lugar mais além da tabela de clientes. TUDO sobre clientes estará nela e se eu não achar lá é porque não existe porque esse dado não foi considerado suficientemente importante para ser incluído na tabela de clientes.

Desvantagens da Normalização ?

1-Imagine você num Datawarehouse para pegar as informações de uma venda, por exemplo. Temos que unir as informações das tabelas de vendas, notas fiscais, cliente, produtos e preços, pagamentos efetuados. Facilmente chegamos a mais de 10 tabelas unidas para obter a informação de uma venda. A união de diversas tabelas sempre dá trabalho quando é bem feita.

2-Necessidade da criação de um campo de ligação entre as tabelas de cada entidade. Exemplificando, se temos uma venda como definimos qual o cliente que fez a compra ? Precisamos de um campo na tabela de vendas para identificar o cliente que fez a compra. A maneira mais comum de fazer isso é atribuir uma coluna de identificação do cliente ( normalmente um número, melhor definindo, uma chave primária ou um número único para o cliente ) e na tabela colocarmos uma coluna chamada codigo_cliente e colocarmos nela o número do cliente que fêz a compra. Uma pesquisa comum feita dessa maneira seria assim:

Select * from vendas v inner join clientes c on c.cod_cli = v.cod_cli

Note que devemos estabelecer uma 'constraint' (regra - chave estrangeira ) que só pode inserir uma venda se o cliente já estiver cadastrado primeiramente. Não podemos ter uma venda sem ter o cliente que a fez cadastrado no sistema.

O que é a denormalização

Muitas vezes, especialmente nas ferramentas de OLAP, costumamos denormalizar uma tabela para que todas as informações que sejam necessárias para trabalhar com a 'entidade' estejam juntas na mesma linha de dados. Citando um exemplo, vamos supor que a chave do negócio da minha empresa seja venda de veículos. Portanto a tabela de veículos seria uma tabela chave do meu negócio. Sendo assim na tabela de veículos teríamos todas as informações referentes ao veículo e de todas as etapas envolvidas na passagem dele na empresa, da proposta de vendas, efetivação da venda ( pedido ), nota fiscal,entrega etc. Isso faria com que um veículo cadastrado nessa tabela teria centenas de campos, mas, com certeza, tudo que meu negócio precisa saber sobre aquela 'entidade' estaria nela, num único registro. E não se esqueça do pós-venda e das informações para as montadoras.

Vantagens da Denormalização ?

Como disse acima, uma pesquisa feita para aquela 'entidade' todos os dados necessários estariam num único registro. Não precisaríamos procurar em nenhum outro local qualquer informação para complementar as informações da 'entidade'. Isso em termos de computador, um único acesso traz todos os dados necessários. Em matéria de disco um grande ganho.

Desvantagens da Denormalização ?

1-Dependendo da 'denormalização' feita um registro de dados pode ter centenas de campos. Com isto se precisarmos identificar o cliente na tabela de vendas, por exemplo, precisaríamos ir campo a campo por centenas de campos até encontrar o campo codigo_cliente. Eu, por exemplo, faço um select top 1 * from tabela e colo a primeira linha, com cabeçalhos num excel ou bloco de notas e ai procuro por cliente. O ruim desse método é quando não normalizamos os nomes e nosso cliente passa a ser cli ou coisa parecida. Precisamos saber até como procurar pelo campo.

2-Os resultados das pesquisas trazem mais dados ( pois uma 'entidade' teria centenas de campos ) se a gente não determinar quais campos queremos como resultado dela. E não se esqueça que se um registro tem um monte de dados o acesso ao disco traria mais informações que seriam jogadas fora se não fossem necessárias a nossa pesquisa.

Finalizando

Como disse no começo deste documento não existe o certo e o errado, depende das circunstâncias de sua utilização. Muitas vezes o erro parece ser tudo normalizado ou tudo 'denormalizado'. Ambos os métodos se complementam e devem ser utilizados conforme a necessidade.